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COMMENT  -  Durra,  also  called  “Indian  millet"  and  “Guinea  corn,"  is  a  type  of  gram  sorghum 
with  slender  stalks,  widely  grown  in  warm  dry  regions.  Durra  sounds  like  “durable"  which 
isn  t  a  bad  connotation.  Carnegie  Institute  personnel  indicated  that  com  is  by  far  the 
largest  in  size  of  all  grains.  We  respectfully  declined  their  suggestion  for  a  name  denoting 
"largest  gram." 


1.  Introduction 

Many  computation-intensive,  real-time  applications  require  efficient  concurrent  execution  of  multiple  tasks 
devoted  to  specific  pieces  of  the  application.  Typical  tasks  include  sensor  data  collection,  obstacle 
recognition,  and  global  path  planning  in  robotics  and  vehicular  control  applications.  Since  the  speed  and 
throughput  required  of  each  task  may  vary,  these  applications  can  best  exploit  a  computing  environment 
consisting  of  multiple  special  and  general  purpose  processors  that  are  logically,  though  not  necessarily 
physically,  loosely  connected.  We  call  this  environment  a  heterogeneous  machine. 

During  execution  time,  processes,  which  are  instances  of  tasks,  run  on  possib.>  separate  processors,  and 
communicate  with  each  other  by  sending  messages  of  different  types.  Since  the  patterns  of 
communication  can  vary  over  time,  and  the  speed  of  the  individual  processors  can  vary  over  a  wide 
range,  additional  hardware  resources,  in  the  form  of  switching  networks  and  data  buffers  are  required  in 
the  heterogeneous  machine. 

The  application  developer  is  responsible  for  prescribing  a  way  to  manage  all  of  these  resourcec.  We  call 
this  prescription  a  task-level  application  description.  It  describes  the  tasks  to  be  executed,  the  possible 
assignments  of  processes  to  processors,  the  data  paths  between  the  processors,  and  the  intermediate 
queues  required  to  store  the  data  as  they  move  from  source  to  destination  processes.  A  task-level 
description  language  is  a  notation  in  which  to  write  these  application  descriptions.  The  problem  we  are 
addressing  is  the  design  of  a  task-level  description  language. 

We  are  using  the  term  description  language  rather  than  programming  language  to  emphasize  that  a 
task-level  application  description  is  not  translated  into  object  code  of  some  kind  of  executable  "machine 
language."  Rather,  it  is  to  be  understood  as  a  description  of  the  structure  and  behavior  of  a  logical 
machine,  that  will  be  synthesized  into  resource  allocation  and  scheduling  directives.  These  directives  are 
to  be  interpreted  by  a  combination  of  software,  firmware,  and  hardware  in  a  heterogeneous  machine. 

Although  our  ultimate  goal  is  to  design  and  implement  a  task-level  description  language  that  can  be  used 
for  different  machines  and  for  varying  applications,  our  first  pass  is  influenced  by  both  a  specific 
architecture,  HETO  [4],  and  by  a  specific  application,  the  Autonomous  Land  Vehicle  (ALV),  and  more 
specifically,  the  perception  components  of  the  ALV-^5J."  We  assume  there  is  a  cross-bar  switch,  intelligent 
buffers  on  the  switch  sockets,  and  a  scheduler  that  can  communicate  with  all  processors,  buffers,  and  I/O 
devices. 

1.1.  Scenario 

Here  is  a  scenario  from  the  user's  viewpoint  of  how  the  task-level  language  is  used  to  help  develop  an 
application  to  run  on  some  target,  heterogeneous  machine.  We  see  three  distinct  phases  in  the  process; 

1 .  the  creation  of  a  library  of  tasks, 

2.  the  creation  of  an  application  description,  and 

3.  the  execution  of  the  application. 
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Library  creation  activities 

These  happen  early  in  the  life  of  an  application,  when  the  primitive  tasks  are  defined. 

1. The  developer  breaks  the  application  into  specific  tasks.  Typical  tasks  are  sensor 
processing,  feature  recognition,  map  database  management,  and  route  planning.  Other 
tasks  might  be  of  a  more  general  nature,  such  as  sorting,  array  operations,  etc. 

2.  The  developer  writes  code  implementing  the  tasks.  For  a  given  task,  there  may  be  possibly 
many  implementations,  differing  in  programming  language  (e.g.,  one  written  in  C  or  one 
written  in  W2),  processor  type  (e.g..  Motorola  68020  or  IBM  1401),  performance 
characteristics,  or  other  attributes.  The  writing  of  a  task  implementation  is  more  or  less 
Independent  of  Durra  and  involves  the  coding,  debugging,  and  testing  of  programs  in 
various  languages  executing  on  various  machines. 

3.  The  developer  writes  task  descriptions  and  enters  them  into  the  library.  This  is  where  Durra 
first  enters  the  picture.  Durra  is  used  to  write  specifications  of  each  task’s  performance  and 
functionality,  the  types  of  data  it  produces  or  consumes,  and  the  ports  it  uses  to 
communicate  with  other  tasks. 

Description  creation  activities 

These  happen  when  the  user  decides  to  put  together  an  application  (say,  autonomous  land  vehicle)  using 

as  building  blocks  tasks  in  the  library. 

1 .  The  user  writes  a  task-level  application  descnption.  Syntactically,  a  task-level  application 
description  is  a  single  task  description  and  could  be  stored  in  the  library  as  a  new  task.  This 
allows  writing  hierarchical  task-level  application  descriptions. 

2.  The  user  compiles  the  description.  During  compilation,  the  compiler  retrieves  task 
descriptions  matching  the  task  selections  specified  by  the  user  from  the  library  and 
generates  a  set  of  resource  allocation  and  scheduling  commands  to  be  interpreted  by  the 
scheduler. 

3.  The  user  links  the  output  of  the  compiler  with  run-time  support  facilities,  obtaining  a 
scheduler  program. 

Application  execution  activities 

1. The  scheduler  downloads  the  task  implementations,  i.e.,  code,  to  the  processors  and 
interprets  the  scheduling  commands  and  initialization  code  for  the  machine. 

2.  The  heterogeneous  machine  runs  the  processes  on  processors  as  dictated  by  the 
scheduler  program. 


1.2.  Terminology 

Durra  is  used  for  describing  process  interaction  at  a  logical,  not  physical,  level,  and  thus  it  can  be  used 
independently  of  any  physical  configuration  of  an  actual  heterogeneous  machine.  We  will  use  different 
terms  to  distinguish  between  the  physical  network  (P)  of  processors,  memories,  and  switches 
implementing  the  heterogeneous  machine,  and  the  logical  network  (L)  of  processes  and  data  queues 
implementing  the  application  (A).  Figures  1  and  2,  respectively,  illustrate  the  physical  and  logical 
components  of  the  system. 

buffers  (P)  computers  acting  as  input  or  output  devices,  Interfacing  processors  with  the  switch. 

As  an  optimization,  buffers  execute  predefined  tasks  such  as  merge,  deal,  broadcast, 
and  data  transformations. 

implementation  (A)  code  written  in  some  programming  language  for  a  specific  processor,  and  satisfying 
the  performance,  functional,  and  other  requirements  specified  in  a  task  description. 

processes’  logical  input  or  output  devices.  Input  ports  remove  data  from  queues; 


ports  (L) 
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process  (L) 


processor (P) 


queue  (L) 
scheduler  (P,  L) 
switch  (P) 


output  ports  deposit  data  in  queues. 

a  uniquely  identifiable  instance  of  a  task,  running  on  a  processo  of  the  heterogeneous 
system.  The  same  task  may  be  instantiated  any  number  of  times  to  obtain  multiple 
processes  executing  the  same  code. 

a  computer  in  the  heterogeneous  system,  not  to  be  confused  with  the  scheduler 
processor  or  the  buffers.  Each  processor  in  the  heterogeneous  system  has  one  or 
two  buffers  that  act  as  interlaces  between  the  processor  and  the  switch.  Processors 
send  data  to  and  receive  data  from  buffers  as  their  means  of  communication  with 
other  processors. 

a  uniquely  identifiable  logical  link  between  tv'o  processes,  following  a  FIFO  discipline. 
Queues  serve  as  intermediaries  between  input  and  output  ports. 

a  compute''  serving  as  resource  allocator  and  dispatcher  in  the  heterogeneous 
system.  It  controls  the  switch,  all  processors,  and  all  buffers. 

an  interconnection  network  used  to  tie  together  all  processors  in  the  heterogeneous 
system.  The  switch  mutes  data  between  the  buffers  attached  to  the  processors. 


task  (L,  A)  an  abstraction  of  a  set  of  implementations,  each  written  for  a  class  of  processors, 

implementing  part  of  an  application.  Tasks  are  stored  in  libraries. 

The  processes  of  the  system  am  inipiement^d  by  downloading  and  executing  task  implementations,  i.e., 
programs,  onto  processors  .  f  the  right  kind.  The  queues  of  the  system  are  implemented  by  allocating 
space  in  the  corresponding  'offers’  memories.  This  is  illustrated  in  Figure  3. 


1.3.  Notes  on  Syntax 

To  describe  the  syntax  of  the  Task  Level  Description  Language,  we  use  the  standard  Backus-Naur-Form 
(BNF),  with  the  following  conventions. 

1.  Commas  separate  alternatives.  'Traces  (“{”  and  "}")  indicate  optionality. 

2.  Temiinal  symbols  are  enclosed  in  qv'otes  ("  and  ”),  but  the  quotes  do  not  belong  to  the 
terminal. 

3.  No  distinction  is  made  between  upper  and  lower  case  letters  in  terminals  and  non-terminals. 

4.  A  non-terminal  of  the  form  xyz_List,.Q^^3  stands  for  a  list  of  one  or  more  xyz’s  separated  by 
commas,  i.e.,  the  character  not  the  string  “comma.” 

5.  Comments  start  with  the  characters  "  Any  characters  between  and  the  end  of  the 
line  are  ignored. 

6.  Identifiers  are,  in  the  usual  fashion,  sequences  of  letters,  digits,  and  (underscore), 
beginning  with  a  letter. 

7.  Strings  are  arbitrary  sequences  of  Ascii  printable  characters,  enclosed  in  double  quotes  ("). 

A  double  quote  inside  a  string  must  be  written  as  two  consecutive  double  quotes: 

"A  string  with  a  double  quote, inside" 

8.  Integer  and  real  numbers  are  always  decimal,  i.e.,  base  10.  A  real  number  can  terminate 
with  a  period  without  a  fractional  part. 

1 .4.  Keywords  and  Predefined  Identifiers 

Keywords  and  predefined  identifiers  are  highlighted  in  normal  text  by  writing  them  in  bold  face,  or  in 
“quotes”,  respectively.  The  following  words  are  keywords  in  the  language:  after,  and,  array,  ast, 
attributes,  before,  behavior,  bind,  cst,  date,  days,  during,  end,  ensures,  est,  gmt,  hours,  identity,  if. 


Figure  3  —  Mapping  of  Logical 
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Index,  In,  Is,  local,  loop,  minutes,  months,  mst,  not,  of,  or,  out,  ports,  process,  pst,  queue, 
reconfiguration,  remove,  repeat,  requires,  reshape,  reverse,  rotate,  seconds,  select,  signals,  size, 
structure,  task,  then,  timing,  to,  transpose,  type,  union,  when,  years. 

Th^  following  words  are  predefined  identifiers  in  the  language;  “broadcast”,  “current_size", 
“currenljime”,  “deal”,  “de^ay”,  “get”,  “implementation”,  "merge”,  “minusjime”,  “mode”,  “plusjime”, 
"processor”,  “put". 


1.5.  Literal  Values 

Each  of  the  non-terminals  IntegerValue,  RealValue,  StringValue,  and  TimeValue  stands  for  (a)  literals 
(constants)  of  the  appropriate  kind,  or  (b)  names  of  attributes  (Section  8)  whose  values  are  literals  of  the 
appropriate  kind,  or  (c)  calls  to  one  of  the  predefined  functions  in  the  language  (Section  10.1)  returning 
values  of  the  appropriate  kind: 

IntegerValue  : :=  IntegerLiteral  , 

Global At trName  , 

FunctionCall 

RealValue  ; ; =  RealLiteral  , 

Globa lAt trName  , 

FunctionCall 


StringValue 


TimeValue 


;  ;=  StringLiteral  , 
GlobalAttrName  , 
FunctionCall 

:  :=  TimeLiteral  , 

GlobalAttrName  , 
FunctionCall 


1.6.  How  To  Read  This  Manual 

This  manual  is  written  top-down,  so  the  reader  should  be  aware  that  there  are  many  forward  references. 
One  can  read  this  manual  from  beginning  to  end  to  get  an  overview  of  the  language,  and  then  read 
individual  sections  to  understand  the  details  of  each  language  feature. 
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2.  Compilation  Units 

Syntax; 

Compilation  :;=  Con^ilationUnit  List,^^- 

CompilationUnit  : :=  TypeDeclaration  , 

Tas3cDescription 

Meaning: 

There  are  two  kinds  of  compii^.iion  units  (i.e.,  separately  compilable  structures):  type  declarations  and 
task  descriptions. 

Any  number  of  compilation  units  can  be  submitted  to  the  compiler  as  a  group,  in  a  single  text  file.  Each 
unit  is  compiled  in  order,  and  if  no  errors  are  detected,  the  unit  is  entered  into  the  library.  It  can  then  be 
used  by  units  compiled  later,  including  units  submitted  later  in  the  same  compilation. 
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3.  Type  Declarations 

Syntax: 

rypeDe''larat  ion 

:  :  = 

'  'TYPE'  '  TypeName.  '  'IS'  '  TypeStructure  , 
''TYPE''  TypeName  ''IS''  UnionStructure 

TypeName 

:  :  = 

Identifier 

Types tructure 

:  :  = 

'  'SIZE' '  ElementSize  , 

'  'APRAY' '  ArrayDimension  ' 'OF'  '  TypeName 

ArrayDimension 

:  :  = 

'('  IntegerValue_Listgp^^^  ')'  --  Positive 

integer 

ElementSize 

IntegerValue  ,  --  Positive  number  of  bits 

IntegerVaJue  '  'TO' '  IntegerValue 

--  Non-negative  size  range 

Unions tructure 

:  :  = 

"UNION"  '('  TypeName_List^^^  ')' 

Examples: 

*ype  packot  is  size  128 

to  1024; 

--  Packata  ara  of  variable  length 

type  tails  'S  array  (5  10)  of  packet;  —  Tails  are  5  by  10  arrays  of  packets 

type  mix  is  union  (heads,  tails);  --  Mix  data  could  be  heads  or  tails 

Meaning: 

Type  declarations  are  compilation  units  that  define  the  structure  of  the  data  produced  or  consumed  by  the 
tasks.  A  type  declaration  introduces  a  global  name  for  a  data  type,  or  a  set  of  previously  declared  types, 
which  call  then  be  used  in  port  declarations. 

There  are  two  kinds  of  type  declaralions.  First,  a  type  declaration  can  specify  the  structure  of  the  data 
moving  through  a  process  port.  The  basic  data  type  is  a  sequence  of  bits  of  fixed  or  variable  (but  bound) 
!  ngin.  Mc.'e  complex  types  are  declared  as  multi-dimensional  arrays  of  simpler  types.  Second,  a  type 
can  specify  the  union  of  a  number  of  previously  declared,  i.e.,  named,  types  where  data  items  moving 
through  a  piocess  port  could  be  one  of  any  of  the  member  types. 
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4.  Task  Descriptions 

Syntax: 

TaskDescription  ::=  ''TASK''  TaskName 

Intarf acePart 

{  BehaviorPart  } 

{  AttrDescriptionPart  } 

{  StructurePart  } 

'  'END' '  TaskName 


Meaning: 

Task  descriptions  are  compilation  units  used  as  building  blocks  for  task-level  application  descriptions. 

A  task  description  is  divided  into  four  components:  (1)  interface  information,  (2)  behavioral  information,  (3) 
attributes,  and  (4)  structural  information.  All  these  components  will  be  described  in  later  sections.  Figure 
4  shows  a  template  for  a  task  description,  where  the  ports  and  signals  clauses  constitute  the  interface 
information. 


task  task-name 

ports  --  REQUIRED 

port-declarations 

--  Daod  for  communication  botwaon  a  procass  and  a  quttua 

signals  --  optional 

signal-  declarations 

--  Daad  for  communication  batweon  a  process  and  th«  achadular 

behavior  --  optional 

function-predicates 
timing-expressions 

--  A  daacription  of  th«  behavior  of  the  task 

attributes  —  optional 

attribute-value-pairs 

--  Additional  propertiea  of  the  task 

structure  —  optional 

process-declarations 
queue-declarations 
binding-declara  tions 
reconfiguration- statements 

--  A  process-queue  graph  describing  the  internal  structure  of  a  task 
end  task-name; 


Figure  4:  A  Template  for  Task  Descriptions 
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5.  Task  Selections 

'  'TASK' '  TaskName 

{  PortDeclarationPart  } 

{  SignalDeclarationPart  } 

{  BehaviorPart  } 

{  AttrSelectionPart  } 

{  '  'END' '  TaskName  } 

Meaning: 

Task  selections  are  templates  used  to  identify  and  retrieve  task  descriptions  from  the  library. 

A  given  task,  e.g.,  convolution,  might  have  a  number  of  different  implementations  that  differ  along 
dimensions  such  as  algorithm  used,  code  version,  performance,  or  processor  type.  In  order  to  select 
among  a  number  of  alternative  implementations,  the  user  provides  a  task  selection  as  part  of  a  process 
declaration,  as  described  in  Section  9.1.  This  task  selection  lists  the  desirable  features  of  a  suitable 
implementation. 

Syntactically,  a  task  selection  looks  somewhat  like  a  task  description  without  the  structure  part,  and  all 
other  components  except  for  the  task  name  are  optional.  For  example,  notice  that  in  the  syntax  of  a  task 
declaration,  the  interface  part  (Section  6)  requires  the  declarations  of  the  ports,  whereas  in  a  task 
selection,  the  declaration  of  the  ports  is  optional.  Figure  5  shows  a  template  for  a  task  selection.  For 
brevity,  if  only  the  task  name  is  given,  the  terminating  “end  task-name”  is  optional. 


Syntax: 

TaskSe lection 


task  task-name  —  REQUIRED 

ports  --  OPTIONAL 

port-declarations 

--  A  signature  that  must  match  port  directions  and  types  of 
--  that  of  a  task  description  in  the  library. 

signals  —  OPTIONAL 

signal-declarations 

A  signature  that  must  match  signal  directions  and  namea  of 
---  that  of  a  task  description  in  the  library. 

beha  ior  --  optional 

fu  n '  non  -predica  tes 
timing-expressions 

--  A  specification  of  the  desired  functionality  and  timing  behavior  of 
--  that  of  a  task  description  in  the  library. 

attributes  --  optional 

a  ttribute-  value-pairs 

-  ■  Named  (actual)  attributes  used  to  match  (formal)  attributes  of 
--  those  of  a  task  description  in  the  library. 

end  task-name  --  optional  if  only  the  task  name  is  specified 


Figure  5:  A  Template  for  Task  Selections 
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6.  Interface  Information 

Syntax: 

InterfacePart  : :=  PortDeclarationPart  {  SignalDeclarationPart  } 

Meaning: 

The  interface  portion  of  a  task  description  or  a  task  selection  provides  information  about  the  ports  of  the 
processes  instantiated  from  the  task  and  the  signals  used  by  the  processes  instantiated  from  the  task  to 
communicate  with  the  scheduler. 

6.1.  Port  Declarations 
Syntax: 

PortDeclarationPart  ::=  ''PORTS''  PortDeclaration_List^^^^Qj^^j^  ''.w 
PortDeclaration  : ;=  PortName  ''IN''  TypaName 

—  comma 

PortName  List  _  >  ^ ^ 'oUT' '  TypeName 

—  comma  -* 

PortName  ; ;=  Identifier 

Globa iPortName  :; =  {  ProcessName  }  PortName 

Examples: 

ports 

ini;  in  haada; 

outl,  out2 ;  out  tails; 

Meaning: 

A  port  declaration  specifies  the  direction  of  tlie  data  movement  and  the  type  of  data  moving  through  the 
port. 

Port  names  must  be  unique  within  a  task.  Outside  the  task,  ports  are  identified  by  their  global  name, 
obtained  by  prefixing  the  name  of  a  process  (instance  of  a  task)  to  the  name  of  the  port,  e.g.,  p1.out2. 

6.2.  Signal  Declarations 
Syntax: 

SignalDeclarationPart  ''SIGNALS'' 

SignalDeclaration_List,^^^^^^  " ;  " 

SignalDeclaration  :  :=  SignalName_List^Qjjijjj^  ^  y  .  >  f  >  ^ 

SignalName_List^„^  "  :  "  "OUT"  , 
SignalName_List^^^j^ij^^  >  >  .  /  /  '  >  ^  >  'OUT'  ' 

SignalName  :  :=;  Identifier 

GlobalSignalName  ;:=  {  ProcessName  }  SignalName 

Examples: 

signals 

stop,  start,  R«8xim«:  in; 

RangaError,  FormatError:  out; 

Raad:  in  OUt; 
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Meaning: 

Signals  are  special  messages  exchanged  between  a  process  and  the  scheduler.  A  signal  declaration 
specifies  the  direction  of  the  signal.  An  in  signal  is  a  message  that  a  process  can  receive  from  the 
scheduler;  an  out  signal  is  a  message  that  a  process  can  send  to  the  scheduler;  an  in  out  signal  is  used 
for  both  directions  of  communication. 

All  signal  names  must  be  unique  within  a  task.  Outside  the  task,  a  signal  is  identified  by  compounding  the 
name  of  a  process  (instance  of  a  task)  with  the  name  of  the  signal,  e.g.,  pi. Restart. 


6.3.  Rules  for  Matching  Selections  with  Descriptions 

If  a  task  selection  provides  a  port  declaration  clause,  the  port  names  provided  in  the  task  selection 
override  the  port  names  provided  in  the  task  declaration.  The  port  declaration  lists  must  otherwise  be 
identical,  i.e.,  the  number,  the  order,  the  directions,  and  the  types  must  be  identical. 

If  a  task  selection  provides  a  signal  declaration  clause,  the  clause  must  be  identical  to  that  provided  in  the 
task  description,  i.e.,  the  names,  number,  and  directions  must  be  identical. 
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7.  Behavioral  Information 

Syntax: 

BehaviorPart 
FunctionPart 

TimingPart 
predicate 

Meaning: 

The  behavioral  information  part  specifies  functional  and  timing  information  about  the  task. 

The  functional  information  part  of  a  task  description  consists  of  a  pre-condition  (requires)  on  what  is 
required  to  be  true  of  the  data  coming  through  the  input  ports,  and  a  post-condition  (ensures)  on  what  is 
guaranteed  to  be  true  of  the  data  going  out  on  the  output  ports. 

The  timing  information  part  of  a  task  description  consists  of  a  timing  expression  following  the  keyword 
timing,  The  timing  expression  describes  the  behavior  of  the  task  in  terms  of  the  operations  it  performs  on 
its  input  and  output  ports. 

The  formal  meaning  of  the  behavioral  information  is  essentially  based  on  first-order  logic.  In  what  follows, 
we  give  only  an  informal  meaning  of  the  individual  parts  and  their  combination.  See[1]  for  the  formal 
meaning. 

7.1.  Function  Part 

The  functional  information  of  a  task  description  describes  the  behavior  of  the  task  in  terms  of  predicates 
about  the  data  in  the  queues,  before  and  after  each  execution  cycle  of  the  task.  The  Larch  Shared 
Language  is  used  as  the  assertion  language  in  the  predicates  of  these  clauses.  We  restrict  this  section  to 
a  very  brief  outline  of  Larch's  approach. 

Larch  [2,  3]  uses  a  two-tiered  approach  to  specifying  program  modules:  a  trait  defines  state-independent 
properties,  and  an  interface  specification  defines  state-dependent  properties  of  a  program.  A  trait  is 
written  in  the  Larch  Shared  Language  (LSL),  and  it  provides  the  assertion  language  used  to  express  and 
define  the  meaning  of  the  predicates  of  an  interface  specification. 

For  a  program  module  such  as  a  procedure,  a  Larch  interface  specification  is  written  in  a  Larch  Interface 
Language  and  contains  predicates  about  the  states  before  and  after  the  execution  of  the  procedure.  The 
Larch  Interface  Language  (LIL)  to  be  used  is  specific  to  the  programming  language  in  which  the 
procedure  is  written  (e.g.,  C,  CommonLisp,  or  Ada.) 


:  ''BEHAVIOR''  FunctionPart  TimingPart 

:  {  ''REQUIRES''  ' predicate  ' ” '  } 

{  ''ENSURES''  predicate  '"'  } 

;  ^  ''TIMING''  TimingExpression  } 

;  Larch  Predicate^ 


’Essentially,  a  first-order  assertion,  [2], 
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7.1.1.  Larch  Traits  and  Specifications 

Figure  6  depicts  a  Larch  (two-tiered)  specification  of  queues  with  “out”  and  "get”  operations.  The  top  part 
of  the  specification  (Figure  6. a)  is  a  trait  written  in  LSL  used  to  describe  values  of  queues.  A  set  of 
operators  and  their  signatures  following  introduces  defines  a  vocabulary  of  terms  to  denote  values  of  a 
type.  For  example,  Empty  and  lnsert(Empty,  5)  denote  two  different  queue  values.  The  set  of  equations 
following  the  constrains  clause  defines  a  meaning  for  the  terms;  more  precisely,  an  equivalence  relation 
on  the  terms,  and  hence  on  the  values  they  denote.  For  exan^ple,  from  the  above  trait,  one  could  prove 
that  First(Rest(lnsert(lnsert(Empty,  5),  6)))  =  6. 

The  bottom  part  of  the  specification  (Figure  6.b)  contains  two  interfaces  written  in  a  "generic”  Larch 
interface  language.  They  describe  the  functional  behavior  of  two  queue  operations,  “put”  and  "get” 
(queue  operation  names  are  used  to  write  timing  expressions,  which  are  described  in  Sectici'i  7.2.3.)  A 
requires  is  a  pre-condition  on  the  state  of  an  operation’s  input  data  that  must  be  true  upon  operation 
invocation:  an  ensures  is  a  post-condition  on  the  state  of  an  operation’s  input  and  output  data  that  is 
guaranteed  to  be  true  upon  operation  termination.  An  omitted  predicate  is  taken  to  be  true.  The 
specification  for  "get”  states  that  "g^t”  must  be  called  with  a  non-empty  queue  and  that  it  modifies  the 
original  queue  by  removing  its  first  element  and  returning  1 


QVala  ;  trait 
introduces 
Smpty:  — »  Q 
Inaart:  Q,  E  Q 
Firat:  Q  — >  E 
R«8t:  Q  — *  Q 
iaEmpty:  Q  ->  Bool 
iain:  Q,  E  — ♦  Bool 
constrains  Q  so  that 

0  generated  by  [  Empty,  Inaart  ] 
for  all  q:  Q,  a,  al :  E 

Firat (Inaart (Empty) ,  a) )  =  a 

Firat  (Inaart  (q,  a))  =  if  iaEmpty  (q)  then  a  else  Firat  (q) 

Raat  (Inaart  (q,  a))  =  if  iaEmpty  (q)  then  Errqjty  else  Inaart  (Raat  (q)  ,  a) 
iaEmpty (Empty)  =  trua 
iaEmpty (Inaart (q,  a))  =  falaa 
iaIn (Empty,  a)  =  falaa 

iaIn (Inaart (q,  a),  al)  =  (a  =  al)  |  ialn(q,  al) 

a,  A  Trait  for  Queue  Values 


Put  "  oparation  (q;  quaua,  a:  alamant) 
ensures  q^^^  =  inaart  (q,  a) 

Gat  =  oparation  (q:  quaua)  raturna  (a:  alamant) 
requires  ~i8En^ty(q) 

ensures  =  Raat  (q)  &  a  =  Firat  (q) 

b.  Interfaces  for  Queue  Qperations 


Figure  6:  A  Larch  Two-Tiered  Specification  for  Queues 
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-  7.1.2.  Functional  Specification  of  a  Task 

We  use  a  similar  approach  as  Larch's  for  the  specification  of  the  functional  behavior  of  a  task.  That  is,  we 
view  the  task  as  a  procedure  whose  input  and  output  “parameters'*  are  defined  by  the  ports  of  the  task. 
A  requires  clause  states  what  is  required  to  be  true  of  the  data  coming  through  the  input  ports;  an 
ensures  clause  states  what  is  guaranteed  to  be  tme  of  the  data  going  out  through  the  output  ports. 

If  one  were  to  view  each  cycle  of  a  task  as  one  execution  of  a  procedure,  the  requires  and  ensures  are 
exactly  the  pre-  and  post-conditions  on  the  functionality  of  that  cycle.  An  omitted  predicate  is  taken  to  be 
true. 

These  are  not  assertions  about  the  queues  connected  to  the  ports.  For  instance,  an  assertion  could  be 
made  that  a  datum  of  some  type  was  sent  to  an  output  port.  It  cannot  be  asserted  that  the  datum  is  in  the 
associated  output  queue,  at  the  end  oi  the  task  execution,  because  it  could  have  been  removed  by  then. 

It  is  up  to  the  implementor  of  a  task  to  verify  that  the  functionality  of  the  task  satisfies  the  requires  and 
ensures  predicates.  A  task  description  writer  and  user  may  assume  that  the  task  implementor  performed 
such  verification  either  formally  or  informally. 

For  example,  consider  the  matrix  multiplication  task  in  Figure  7.  The  task  takes  input  matrices  from  two 
queues  and  outputs  the  result  matrix  on  an  output  queue.  The.  requires  clause  states  that  the  task 
implementor  may  assume  that  the  number  of  rows  of  the  matrix  entering  through  the  port  in1  equals  the 
number  of  columns  of  the  matrix  entering  through  in2.  The  ensures  clause  states  that  the  result  of 
multiplying  the  two  input  matrices  is  output  through  the  output  port. 


lask  multiply 
ports 

ini,  in2 :  In  matrix; 
outl:  out  matrix; 
behavior 

requires  "rows  (First  (ini)  )  =  cols  (First  (in2)  )"  ; 
ensures  "Insert (outl,  First  (ini)  *  First (in2) )" ; 
end  multiply; 


Figure  7:  A  Matrix  Multiplication  Task 


7.2.  Timing  Part 

Processes  remove  data  from  their  input  queues  and  store  data  into  their  output  queues  following  a  task- 
specific  pattern  provided  by  a  timing  expression.  A  timing  expression  describes  the  behavior  of  the  task 
in  terms  of  the  operations  it  performs  on  its  input  and  output  ports;  this  is  the  behavior  of  the  task  seen 
from  the  outside. 


7.2.1.  Time  Literals 
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Syntax: 

TimeLiteral 

Date 

years 

months 

days 

TimeOfDay 

hours 

minutes 

seconds 

TimeUnit 


TimeZone 


IndeterminateTime 


{  Date  }  TimeOfDay  {  TimeZone  } 

IndeterminateTime 


■  years  '  '  months  '  '  days 

•  ■=  IntegerValue 

:  :=  IntegerValue 

: :=  IntegerValue 

{  {  hours  }  minutes 

RealValue  TimeUnit  , 
IntegerValue  TimeUnit  , 

: :=  IntegerValue 

:=  IntegerValue 

:  ;=  IntegerValue  , 

RealValue 

::=  ''YEARS"  , 

'  'MONTHS'  '  , 

'  'DAYS'  '  , 

'  'HOURS'  '  , 

' 'MINUTES' '  , 

'  'SECONDS'  ' 


range  is 

1. 

.  12 

range  is 

1. 

.31 

seconds  , 


--  range  is  0 . . 23 
--  range  is  0 . . 59 


: ''EST'' 

' 'CST' ' 

' 'MST' ' 

' 'PST' ' 

' 'GMT' ' 

' 'LOCAL' 
' 'AST' ' 


--  Eastern  Standard  Time 
--  Central  Standard  Time 
Mountain  Standard  Time 
--  Pacific  Standard  Time 
Greenwich  Meridian  Time 
--  Local  Time 
Application  Start  Time 


Examples: 

5:15:00  esl 
15.5  hours  ast 

2:10 


2.1667  minutes 


■* 


An  abBoluf  tiin«:  5  hours  15  minuf »  Eaaf  m  Standard  Tima. 

—  An  application  ralativa  tima:  15  hours  and  30  lainutas 
—  aftar  tha  start  of  tha  application. 

—  An  avant  ralativa  tima:  2  minutas  10  saconds 
--  aftar  soma  basa  avant . 

—  Approximataly  tha  sama  avant  ralativa  tima  as  abova 
—  10  aaconds  is  l/6th  of  a  minuta. 


Anuauarminaca  point  in  tima. 

Meaning: 

Time  values  are  used  to  specify  points  in  time.  These  can  be  either  (1)  absolute  i  e  independent  of  the 
application,  in  which  case  they  must  be  followed  by  the  name  of  a  time  zone;  (2)  relatiw  to  the  application 
stad  time,  in  which  case  they  must  be  followed  by  the  fictitious  time  zone  4r;  or  S 
prior  event  in  the  application,  in  which  case  neither  a  date  nor  a  time  zone  is  allowed. 


The  notation  allows  for  alternative  ways  of  denoting  time  of  day  or  time  elapsed  between  events  Time 
epresents  number  of  seconds.  Time  can  also  be  expressed  as  a  multiple  of  other  time  units  by  writing 


T- 
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a  number  followed  by  a  unit  name  such  as  seconds,  minutes,  hours,  days,  months,  or  years.  The  use 
of  seconds  as  a  time  unit  is  redundant,  but  allowed  for  completeness’  sake.  The  format  adopted  by  a 
user  might  depend  on  the  nature  of  the  application,  on  any  standard  conventions  in  the  application 
domain,  on  the  magnitude  of  the  time  scale,  on  the  precision  required,  or  simply  on  aesthetic,  personal 
preferences. 

7.2.2.  Event  Expressions  and  Time  Windows 
Syntax: 

EventExpression 

TimeWindow 
QueueOperation 

Examples: 

ini 

ini . gat 

inl.gat[5,  15] 
dalay[10,  15] 
dalay[*,  10] 
d«lay[10,  *] 

Meaning: 

Queue  operations  performed  by  the  processes  constitute  the  basic  events  of  an  application  description. 
An  event  expression  represents  a  queue  operation  on  a  queue  attached  to  a  specific  port,  taking  a 
variable  amount  of  time  to  complete.  A  pseudo-operation,  “delay”,  is  used  to  represent  the  time 
consumed  by  the  process  between  (real)  queue  operations. 

The  name  of  the  queue  operation  is  optional.  If  the  name  is  not  given,  a  default  queue  operation  is 
assumed:  “get”  for  input  ports,  “put”  for  output  ports.  The  complete  list  of  queue  operations  is 
configuration  dependent,  as  described  in  Section  10.4. 

Time  windows  are  used  to  describe  the  duration  of  a  queue  operation  or  the  delay  between  two 
operations.  Time  windows  are  denoted  by  a  pair  of  time  values  [Tmin'^maxl  defining  the  boundaries  of  the 
interval. 

The  time  window  associated  with  a  queue  operation  describes  the  minimum  and  maximum  time  needed 
to  perform  the  operation.  This  time  window  is  optional,  and  if  it  is  missing,  a  configuration  dependent, 
default  window  is  assumed,  as  described  in  Section  10.4.  Intervals  of  time  between  queue  operations  are 
denoted  by  a  “delay”  operation  whose  time  window  describes  the  minimum  and  maximum  time 
consumed  by  the  process  in  between  queue  operations. 


:  ;=  GlobalPortName 

{  '  ' .  '  '  QueueOperation  ) 

{  TimeWindow  } 

' 'DELAY' '  TimeWindow 

:  ;=  TimeValue  Time Value 

::=  Identifier  --  Configuration  dependent 

--  An  oparation  (gat,  by  dafault)  on  tha  quaua  faading  port  ini. 

--  An  oparation  taking  a  aystam  dafault  tinia  to  coiripiata. 
--  An  oparation  taking  batwaan  5  and  15  aaconds  to  complata. 

--  A  dalay  intarval  lasting  batwoan  10  and  15  aaconda. 

--  A  dalay  intarval  taking  at  moat  10  aaconda. 
--  A  dalay  intarval  taking  at  laaat  10  aaconda . 
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7.2.3.  Timing  Expressions 
Syntax: 

TimingExpression  ::=  {  ''LOOP''  )  CyclicTiiningExpression 

CyclicTimingExpression  : :=  ParallelEventExpres3ion_List^p^^^^ 

ParallelEventExpression  :  :=  BasicEventExpres3ion_List^Q^j^^  vertical  bar 

BasicEventExpres3ion  ; :=  EventExpres3ion  , 

{  Guard  }  '('  CyclicTimingExpresaion  ')' 

Guard  : ' 'REPEAT' '  IntegerValue  , 

'  'BEFOFIE'  '  TimeValue  ,  --  Absolute  time 

' 'AFTER' '  TimeValue  ,  --  Absolute  time 

'  'DURING'  '  TimeWindow  ,  --  T„.  is  Absolute  time 

'  nun 

''WHEN''  '"'  predicate 
predicate  :  :  Larch  Predicate 

Examples: 

ini  II  in2[10,15]  —  Two  parallal  input  operations,  starting  simultaneously. 

ini [0,5]  delay [10, 15]  outl  --  Two  sequential  inputs  operations  with  an  inteirvening  delay. 

repeat  5  =>  (ini  [0,5]  delay  [10,  15]  outl)  --  Same  as  above  but  as  a  cycle  repeated  five  times. 

before  18:00:00  local  =>(...)  --  A  sequence  constrained  to  start  before  6  pm. 

after  18;00:00  local  =>{...)  --  A  sequence  constrained  to  start  after  6  pm. 

during  [18:00:00  local,  12  hours]  =>(...)  —  A  sequence  constrained  to  start  at  night. 

when  -empty (ini)  and  -empty (in2)  =>  ((ini. get  ||  in2.get)  outl. put); 

--  A  sequence  constrained  to  start  after  both  input  queues  have  data. 

loop  when  ~empty(inl)  and  ~empty(in2)  =>  ((ini. get  ||  in2.get}  outl. put); 

--  The  same  sequence  as  abovm  but  repeated  indef inetely . 

Meaning: 

A  timing  expression  is  a  regular  expression  describing  the  patterns  of  execution  of  operations  on  the  input 
and  output  ports  of  a  task.  The  keyword  loop  can  be  used  to  indicate  that  the  pattern  of  operations  is 
repeated  indefinitely. 

A  timing  expression  is  a  sequence  of  parallel  event  expressions.  Each  parallel  event  expression  consists 
of  one  or  more  event  expressions  separated  by  the  symbol  "H”  to  Indicate  that  their  executions  overlap. 
Since  the  expressions  might  take  different  amounts  of  time  to  complete,  nothing  can  be  said  about  their 
completion,  other  than  a  parallel  event  expression  terminates  when  the  last  event  terminates. 

Parallel  events  start  simultaneously  but  are  not  necessarily  completed  at  the  same  time.  In  the 
expression  “(ini  ||  in2[10,15])”,  the  duration  of  the  input  operation  on  port  in1  defaults  to  some 
configuration-dependent  value  (See  Section  10.4)  and  might  be  shorter  or  longer  than  the  explicit 
duration  of  the  input  operation  on  port  in2,  i.e.,  between  10  and  15  seconds. 

A  basic  event  expression  Is  either  a  queue  operation  (including  “delay”)  or  a  timing  expression  enciosed 
in  parentheses.  The  latter  form  also  allows  for  the  specification  of  a  guard,  an  expression  specifying  the 
conditions  under  which  a  sequence  of  operations  is  allowed  io  start  or  repeat  its  execution. 


^Essentially,  a  first-order  assertion,  [2] 
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Guard  Description 

repeal  This  guard  indicates  repetitions  of  a  timing  expression.  The  number  of  repetitions  is 

a  non-negative  integer  value. 

before  This  guard  is  followed  by  an  absolute  time  value  representing  the  latest  start  time 

allowed.  If  the  deadline  does  not  include  a  date,  i.e.,  it  is  just  a  time  of  day,  and  the 
deadline  has  passed,  then  the  sequence  is  blocked  at  most  until  midnight  of  tho 
current  date  and  will  unblock  at  “00:00:00"  of  the  following  day.  The  task  is 
terminated  if  a  dated  deadline  has  passed. 

after  This  guard  is  followed  by  an  absolute  time  value  representing  the  earliest  start  time 

allowed.  If  necessary,  the  sequence  is  blocked  until  the  deadline.  If  the  deadline 
does  not  include  a  date,  i.e.,  it  is  just  a  time  of  day,  then  the  sequence  is  blocked  at 
most  24  hours.  For  example,  if  it  is  "00:00:00.000”  and  the  deadline  is 
"23:59:59.999"  the  sequence  will  unblock  at  the  end  of  the  day. 

during  This  guard  is  followed  by  a  time  window  during  which  the  sequence  is  allowed  to 

start.  The  first  value  is  the  earliest  start  time  allowed  and  must  be  an  absolute  time 
value;  the  second  value  is  the  latest  start  time  allowed  and  can  be  an  absolute  time 
value  or  a  time  value  relative  to  the  former. 

when  This  guard  describes  what  is  required  to  be  true  of  the  state  of  the  system  (i.e.,  time 

and  queues,  see  Section  10.1)  before  the  sequence  is  allowed  to  start.  It  is  a  pre¬ 
condition  for  starting  the  sequence. 

7.2.4.  Restrictions  on  Time  Values  and  Time  Windows 

Although  the  syntax  allows  both  absolute  and  relative  time  values  to  appear  in  either  of  the  two 

boundaries  in  a  time  window,  not  all  of  the  possible  combinations  make  sense: 

1 .  A  date  in  a  time  value  that  uses  the  "ast"  time  zone  is  meaningless. 

2.  In  the  time  window  attached  to  a  queue  operation,  including  “delay",  the  time  values  must 
be  relative  (i.e.,  no  dates  or  time  zones  allowed)  and  are  interpreted  relative  to  the  start  of 
the  operation. 

3.  In  the  time  window  of  a  during  guard,  the  first  time  value  (T^,^)  must  be  absolute.  The 
second  time  value  (T^^)  can  be  absolute  or  relative.  In  the  latter  case,  the  time  value  is 
relative  to 


7.3.  Rules  for  Matching  Selections  with  Descriptions 

The  meaning  of  the  behavioral  information  is  a  predicate,  M^(R,  T)  =>  M^(E,  T),  where  R  is  the  requires 
predicate,  E  is  the  ensures  predicate,  T  is  the  timing  expression,  and  is  the  meaning  function 
mapping  a  predicate  and  timing  expression  into  a  boolean  [1]. 

A  task  description  matches  a  task  selection  if  the  predicate  associated  with  the  behavioral  information  of 
the  task  description  implies  that  of  the  task  selection.  If  no  timing  expression  appears,  the  predicate 
simplifies  to  R  =>  E,  and  that  of  a  task  description  must  imply  that  of  the  task  selection. 

Currently  there  are  no  facilities  to  check  these  implications  and  timing  expressions,  so  for  the  time  being 
the  behavioral  information  part  of  a  task  description  is  treated  as  commentary  information.  However, 
timing  expressions  are  used  to  simulate  the  behavior  of  a  task  and  are  therefore  required  by  the  simi'lator 
[61. 
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8.  Attributes 

Syntax: 

AttrDescriptionPart 

:  :  = 

'  'ATTRIBUTES'  '  AttrDescript ion_List^^^^^j^^^  >  >  .  w 

At trDe script ion 

:  :  = 

AttrName  '  '  =  ' '  AttrValue 

Att rSelectionPart 

:  :  = 

'  'ATTRIBUTES'  '  Att rSelect ion_Listg^^^^ .  r  . 

Att rSelection 

:  :  = 

AttrName  ' '=' '  AttrDis junction 

At tr Name 

:  :  = 

Identifier 

Globa 1 At trName 

:  :  = 

{  ProcessName  ' ' . ' '  }  AttrName 

Att rDis junction 

;  :  = 

AttrCon junction  , 

AttrDis junction  ' 'OR' '  AttrCon junction 

At trCon junction 

;  ;  = 

At trP rimary, 

AttrCon junction  ' 'AND' '  AttrPrimary 

At trP rimary 

‘  r  — 

AttrTerm  , 

' 'NOT' '  AttrTerm 

AttrTerr 

:  :  = 

AttrValue  , 

'('  AttrDisjunction  ')' 

AttrValue 

OtherAtt rValue  , 

'('  OtherAttrValue  hist___.  ')'  , 

ModeAttrValue  , 

ImplementationAttrValue  , 

ProcessorAtt rvalue  , 

OtherAtt rvalue 

IntegerValue  , 

RealValue  , 

StringValue  , 

TimeValue 

Examples: 

attributes 

author  =  "jmw"; 

—  Attributaa  in  a  task  declaration 

color  =  ("r®d’',  "whit®",  "blu®"); 
implomantation  =  "/uar/ jinw/alv/cowcatch®r .  o"  ; 

Que’a®_Sizc  =  25  ; 

attributes  —  Attributaa  in  a  taak  aalaction 

author  =  "jmw"  or  "mrb"; 

color  =  "rad"  and  "blua"  and  not  ("graan"  or  "yallow"); 
procaaaor  =  Warpl; 
mod®  =  groupad_by_4 ; 

Meaning: 

Attributes  specify  miscellaneous  properties  of  a  task.  They  are  a  means  of  indicating  pragmas  or  hints  to 
the  compiler  and/or  scheduler.  In  a  task  description,  the  developer  of  the  task  lists  the  possible  values  of 
a  property;  in  a  task  specification,  the  user  of  a  task  lists  the  desired  values  of  a  property.  All  attribute 
values  used  in  matching  task  selections  with  task  descriptions  must  be  constants,  computable  before 
execution  time,  i.e.,  tasks  and  their  implementations  are  static  properties  of  an  application. 

Example  attributes  include:  author,  version  number,  programming  language,  file  name,  and  processor 
type.  There  may  be  as  many  attributes  as  desired.  Attributes  defined  in  other  tasks  can  be  accessed  by 
prefixing  the  name  of  the  attribute  with  the  name  of  a  process  instantiated  from  that  task,  e.g.,  pi  .author. 


22 


The  name  of  an  attribute  can  appear  in  any  context  in  which  its  value  can  appear.  For  instance,  if  the 
user  defines  an  at  '  '*e  ‘■Cueue_Size'’  as  in  the  examples  then  '‘Queue_Size”  can  appear  anywhere  an 
integer  value  is  e?  .a.  This  permits  the  user  to  name  say,  a  jjueue  size  and  use  the  name  to  declare 
queues  with  idenu,  ^1  size  in  a  number  of  task  descriptions.  Another  use  is  to  instantiate  "families”  of 
tasks,  i.e.,  tasks  that  sha.'t^  the  same  value  for  some  attribute,  as  shown  in  Figure  8. 


process 

Haator_Procoaa  :  task  Maator_Ta8k.  ■-  A  taak  aoloction 

attributes 

Koy_Naino  =  some  velue; 

.  .  other  attributes,  maybe  .  . 

end  MaBtor_Ta8)t; 

pi :  task  foo 

attributes 

K«y_Nam«  =  Maator_Proc«8a . K«y_Nam«;  --  Samo  valua  as  Maator_Proc«aa 

...  other  attributes,  maybe ... 
end  foo; 

p2  :  task  bar 

attributes 

K«y_Nain«  =  Maat«r_Procaaa  .K«y_Nai\)«;  --  Sana  valua  as  Mas tar_Proca88 

...  Other  attributes,  maybe  ... 
end  bar; 


Figure  8:  Use  of  Global  Attribute  Names 


The  syntax  and  semantics  of  the  attribute  values  are  attribute  dependent.  If  the  attribute  is  not  predefined 
in  the  language,  the  values  are  treated  as  uninterpreted  numbers,  time  values,  or  strings,  as  the  case 
may  be,  and  compatibility  is  based  on  value  equality.  If  the  attribute  is  predefined  in  the  language,  the 
syntax  for  the  legal  values  is  given  in  Section  10.2,  and  compatibility  is  attribute  dependent. 

The  following  attributes  are  predefined  in  the  language;  "mode”  (specifies  the  mode  of  operation  for  a 
deal  or  merge  predefined  task);  "implementation”  (specifies  the  location  of  the  task  implementation);  and 
"processor”  (specifies  the  processor  type  on  which  the  implementation  can  run).  These  are  described  in 
Section  10.2. 

8.1.  Rules  for  Matching  Selections  with  Descriptions 

If  a  task  selection  specifies  an  attribute  not  present  in  a  task  description,  no  match  occurs,  i.e ,  the 
compiler  skips  this  description  and  continues  searching  for  a  candidate.  If  a  task  description  provides  an 
attribute  not  specified  in  a  task  selection,  the  attribute  is  ignored. 

If  a  task  selection  provides  a  predicate  (a  disjunction)  for  an  attribute,  a  matching  task  description  must 
provioe  values  that  satisfy  the  predicate,  i.e.,  the  disjunction  yields  true  when  evaluated  in  the  context  of 
the  values  declared  for  the  attribute.  If  a  task  description  provides  a  single  value  for  an  attribute,  a 
matching  task  selection  must  provide  exactly  that  value. 
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9.  Structural  Information 
Syntax: 

StructurePart  : :=  ' 'STRUCTURE' ' 

StructureClause_List^p^^^ 

{  Reconf igurationClause-List^p^^^  } 

StructureClause  ;  '  'PROCESS'  '  P  :ocessDeclarationList,^^.^„.,^„  '  , 

'  'QUEUE'  '  QueueDeclaraticn_List^^^^3^^^  ^  ^  ^ 

'  'BIND'  '  PortBinding_List^^^^i^„  "  ;  " 

Reconf igurat ionClause  ; :=  ' 'RECONFIGURATION' ' 

Reconf  iguration_List^^^^^^„  "  ;  " 

Meaning: 

Process  and  queue  declarations  appear  under  the  keyword  structure  in  a  task  description.  These 
declarations  define  a  graph  in  which  processes  are  the  nodes,  and  queues  are  the  links.  These  graphs 
depict  the  internal  structure  of  a  compound  task.  The  structure  part  of  a  task  description  provides  the 
means  for  developing  hierarchical  task  descriptions. 

9.1.  Process  Declarations 
Syntax: 

ProcessDeclaration  :;=  P.rocessNaine  List  _ _  _  skSelecrion 

—  coxnxuA 

Examples: 

pi:  task  obstacl«_f indor; 

p2  :  task  obatacl«_f indor  ports  foo:  in,  bar:  out  end  obstacla_f indar ; 
p3,  p4 :  task  obatacl«_f  indar  attributes  author="mrb''  end  obatacl«_f indar ; 

Meaning: 

An  instance  of  a  task  is  bound  to  each  process’s  name.  The  name  of  a  task  is  the  minimal  part  of  a  task 
selection.  Local,  actual  names  (e.g.,  ports  “foo"  and  “bar”  in  the  example)  can  be  introduced  by 
providing  a  port  declaration,  provided  that  Ute  types  of  ports  specified  in  the  task  declaration  are  identical 
to  those  provided  in  the  task  selection.  If  they  are  left  out,  the  formal  names  used  in  Use  task  description 
are  used  instead. 

9.2.  Queue  Declarations 
Syntax: 

QueueDeclaration  ;:=  QueueName  {  QueueSize  }  QueueDef inition 

QueueDef inition  : :=  GlobalPortName 

'  '>' '  ProcessName  ' '>'  ' 

GlobalPortName 
Globr iPortName 

' '>' '  Transf ormExpression 
GlobalPortName 

: :=  Identifier 


QueueNanie 
QueueSize 
GlobalQueueNam'  • 


'  '  [ ' '  IntegerValue  ' ' ]  '  ' 

{  ProcessName  ' '  .  '  '  }  QueueName 


'>'  ' 
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Examples: 

ql:  pi  >  >  p2  ;  --  Two  ports  conn«ct«d  through  an  unbounded  qu«u«. 

--  Tha  two  ports  must  hava  tha  sama  typa. 

ql:  pi  >  (2  1)  transpose  >  p2  ;  —  Two  ports  connactad  through  an  unboundad  quaua. 

--  Tha  data  arrays  ara  transposad  in  tha  quaua. 

ql[100] :  pi  >  xyr  >  p2  ;  --  Two  porta  connactad  through  a  boundad  (siza  =  100)  quaua. 

--  Data  ara  transformad  in  tha  quaua  by  a  procass  '  'xyz'  '  . 

Meaning: 

A  queue  definition  establishes  a  logical  link  between  two  ports  that  communicate  by  passing  data  from  the 
first  port  (source)  to  the  second  port  (destination).  The  queue  name  must  be  unique  within  the  task 
description  defining  the  process-queue  graph.  The  (optional)  queue  bound  declares  the  maximum 
number  of  elements  that  will  be  stored  in  the  queue  at  any  one  time.  If  a  queue  is  full  when  a  “put” 
operation  is  attempted,  the  process  trying  to  store  the  data  waits  until  the  queue  has  space  for  the  new 
item.  If  the  queue  bound  is  not  provided,  a  configuration  dependent,  default  queue  length  is  assumed,  as 
described  in  Section  10.4. 

When  establishing  a  logical  connection,  the  ports  are  checked  for  type  compatibility.  Non-union  types  are 
compatible  if  they  have  the  same  name.  Union  types  are  compatible  if  the  source  set  is  a  subset  of  the 
destination  set.  A  non-union  source  type  is  compatible  with  a  union  destination  type  if  the  source  type 
name  is  a  member  of  the  destination  set. 

If  the  types  are  not  compatible,  the  user  must  provide  a  data  transformation  operation  that  will  convert 
objects  of  one  type  into  the  other  as  described  below 

9.3.  Data  Transformations 

Data  transformations  are  operations  applied  to  data  coming  from  a  source  port  in  order  to  make  them 
acceptable  to  a  destination  port. 

A  data  transformation  is  required  if  the  input  and  output  port  types  are  not  compatible.  Such 
transformations  are  needed  if,  for  instance,  the  types  have  the  same  structure  but  the  data  are  in  the 
wrong  format,  e  g.,  turning  a  square  array  on  its  side  or  converting  between  floating-point  formats. 

Complicated  transformations  can  be  written  as  separate  tasks,  in  which  case  an  appropriate  task  must  be 
selected  and  instantiated  as  a  process,  and  the  process  name  must  be  specified  in  the  queue  declaration. 
Simple  transformations  can  be  specified  directly  in  the  queue  declaration. 

9.3.1.  Off-Line  Data  Transformations 

Complex  data  transformations  can  be  specified  as  regular  tasks  by  writing  a  procedure  in  some 
programming  language  suitable  for  either  the  buffers  or  one  of  the  heterogeneous  processors  and 
entering  an  appropriate  task  description  in  the  library.  These  data  transformation  tasKS  must  declare 
exactly  one  input  port  and  one  output  port. 
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task  comar  turning 
ports 

ini  :  in  landinar)c_row  major; 
outl:  out  landmark  column  major; 
attributes 

implamantation  =  "/'usr/mrb/flcraatch .  o" ; 
procassor  =  buf far_proca8aor ; 
end  cornar  turning; 


9.3.2.  In-Line  Data  Transformations 


Syntax: 

TransformExpression 
Transf ormOp 


ReshapeOp 

SelectOp 

TransposeOp 

RotateOp 

ReverseOp 

DataOp 

Vector Argument 


Transf  ormOp_List:^p^^, 

ReshapeOp  , 

SelectOp  , 

TransposeOp, 

RotateOp, 

ReverseOp, 

DataOp 

Vector Argument  '  'RESHAPE' ' 

ArrayArgument  '  'SELECT'  ' 

Vector Argument  ' 'TRANSPOSE' ' 

ArrayArgument  ' 'ROTATE' ' 

IntegerValue  ' 'REVERSE'  ' 

Identifier 

'('  IntegerValue__Listgp^^^  ')'  , 

'('  IntegerValue  ''IDENTITY''  ')'  , 

'('  IntegerValue  ''INDEX''  ')'  , 

--  Empty  vector 


ArrayArgument  ; :=  VectorArgument  , 

'('  ArrayArgument_Listgp^^^  ')' 

Examples: 

If  the  input  is  a  2x2x3  3-dimensional  array: 

(3  4)  reshape  --  rashapao  tha  input  array  into  a  3x4  2-dimanflional  array. 


(12)  reshape 


--  unravala  tha  array. 


If  the  input  is  a  2-dimensional  array; 

{(5  2  3)  (*))  select  --  ganarataa  an  array  consisting  of  rows  5  2  and  3,  in  that  ordar. 

((*)  (52  3))  select  —  ganaratos  an  array  consisting  of  columns  5  2  and  3,  in  that  ordar. 

(2  1)  transpose  —  Transposas  tha  array  in  tha  normal  mannar. 

(1  -2)  rotate  —  Rotatas  aach  row  laft  1  position  and  than  rotatas 

--  aach  column  of  tha  rasult  down  2  positions. 


Additional  examples: 

(5  identity)  --  Ganaratas  tha  vactor  (11111). 

(5  index)  —  Ganaratas  tha  vactor  (12345). 

--  Ravarsas  tha  alamants  along  tha  2nd  coordinata  of  an  input  array. 


2  reverse 
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Meaning: 

The  most  common  cases  of  data  transformations  are  expected  to  be  n-dimensional  array  manipulations. 
For  these  operations,  the  language  provides  a  shorl-cut:  it  is  not  necessary  to  write  task  implementations, 
i.e.,  program  code,  and  task  descriptions  and  to  enter  them  in  the  library.  It  suffices  to  specify  the 
transformations  as  part  of  the  queue  declaration. 


In-line  data  transformations  are  specified  in  post-fix  notation,  interpreted  left-to-rigfit,  with  arguments 
preceding  the  operators,  and  with  the  input  port  providing  the  initial  argument.  In  general,  the  arguments 
are  multi-dimensional  arrays  (nested  vectors)  of  scalar  data  values. 


Operator  Description 


inwger  identity 
integer  index 
vector  reshape 


array  select 


generates  the  vector  (1  1  ...  1  1). 
generates  the  vector  (1  2  ...  N). 

unravels  an  array  (i.e.,  linearizes  it)  and  then  reshapes  into  an  array  with  the 
dimensionality  of  the  argument  vector.  The  input  array  is  linearized  in  row  order,  i.e., 
by  scanning  all  of  the  positions  varying  the  highest  dimension  first.  This  operation 
must  be  specified  if  the  input  and  output  array  do  not  have  the  same  shape  but  the 
array  elements  are  in  the  right  order  when  the  arrays  are  unraveled. 

extracts  (slices)  pieces  of  a  data  array.  If  the  input  is  a  vector,  (5)  select  represents 
the  5th  element,  and  (5  2  3)  select  is  a  new  vector  consisting  of  the  5th,  2nd,  and  3rd 
elements  in  that  order.  A  vector  of  the  form  “(*)”  selects  all  components  along  one 
dimension. 


vector  transpose  permutes  the  dimensions  of  a  data  array  according  to  the  argument  vector  (V).  The 
i^^  coordinate  of  the  input  array  becomes  coordinate  V[i]  of  the  result. 

scalar_or_vector  rotate 

specifies  rotations  of  n-dimensional  data  arrays.  The  operator  is  preceded  by  an 
argument  which  must  be  either  a  scalar  (signed)  integer  value  or  a  parenthesized 
array  of  (signed)  integer  values.  The  magnitude  of  the  values  specify  the  number  of 
positions  to  rotate  the  input  data,  and  the  sign  of  the  values  specify  the  direction  of 
the  rotation:  a  positive  amount  indicates  rotation  towards  lower  indices. 

A  scalar  argument  specifies  how  to  rotate  an  input  vector.  An  n-length  vector  of 
scalars  specifies  how  to  rotate  an  n-dimensional  input  array  along  each  dimension 
(one  element  per  dimension).  An  n-length  vector  of  vectors  argument  specifies  how 
to  rotate  an  n-dimensional  input  array  along  each  dimension  (one  top  level  vector  per 
dimension)  and  within  each  dimension,  how  to  rotate  each  “row”  (one  element  of  a 
second  level  vector  per  row.) 

For  example,  consider  the  transformation  "((1  2  0)  (-3  -4))  rotate”  applied  to  a  2- 
dimensional  3x2  input  array.  The  vector  (12  0)  specifies  how  to  rotate  the  rows;  the 
vector  (-3  -4)  specifies  how  to  rotate  the  columns.  The  first  row  is  rotated  left  1 
position,  the  second  row  is  rotated  left  2  positions,  the  third  row  is  left  unchanged. 
Then  the  first  column  is  rotated  down  3  positions,  and  finally,  the  second  column  is 
rotated  down  4  positions. 

integer  reverse  reverses  the  order  of  the  elements  of  an  array  along  an  arbitrary  coordinate  specified 
by  the  integer  argument.  If  the  input  is  a  vector,  the  argument  must  be  “1”.  In  the 
transformation  “2  reverse”,  if  the  input  is  a  2-dimensional  array,  this  operation 
shuffles  columns;  if  the  input  is  a  3-dimensional  array,  this  operation  shuffles  planes. 

Data  Operations  scalar  operations  applied  to  each  element  of  an  input  array.  The  set  of  operations  is 
configuration  dependent.  The  initial  set  will  include  operations  to  round,  truncate,  or 
otherwise  convert  between  various  integer  and  floating-point  formats,  as  described  in 
the  configuration  file,  Section  10.4. 

This  is  a  first  attempt  at  defining  the  set  of  the  operations  a  user  is  likely  to  perform  on  n-dimensional 
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arrays.  The  guiding  principle  is  to  keep  the  notation  simple;  more  complex  transformations  should 
probably  be  specified  as  off-line  transformations. 

A  data  transformation  operation  is  more  than  just  a  way  to  achieve  type  compatibility  between  ports.  It 
also  serves  to  specify  operations  that  would  be  inappropriate  or  inefficient  if  written  as  part  of  one  of  the 
tasks.  For  example,  consider  an  application  that  requires  scanning  an  array  in  different  directions  (e.g., 
first  by  rows,  then  by  columns)  and  performing  some  operation  on  each  element  (e.g.,  computing  the 
average  of  the  neighbors).  Rather  than  writing  several  versions  of  the  task,  one  for  each  traversal 
pattern,  one  could  simply  write  one  version  of  the  task,  and  then  instantiate  it  as  many  times  as 
necessary,  each  process  so  instantiated  could  then  take  its  input  arrays  from  queues  that  perform  the 
appropriate  transposition,  as  in  ‘‘q1:p1>(2  1)  transpose>p2”.  Arrays  produced  by  p1  are  transposed 
while  in  the  queue,  before  they  are  delivered  to  p2. 


9.4.  Binding  Port  Names 
Syntax: 

PortBinding  ExtPortName  ' '  IntPortName 

ExtPortName  : :=  PortName  External  port 

IntPortName  -  : GlobalPortName  —  Internal  port 

Example: 

bind 

p  d<aal.inl  =  ob8tacl«_f ind«r .  ini ; 
p_marg« . outl  =  ob8tacl«_f  indar . outl ; 

Meaning: 

A  port  binding  maps  a  port  of  the  process-queue  graph  defining  the  internal  structure  of  a  task  to  a  port 
defining  the  external  interface  of  a  task. 


9.5.  Process-Queue  Graph  Reconfiguration 
Syntax: 

Reconfiguration  :;=  ''IF''  RecPredicate  ''THEN'' 

{  ProcessTermination-Listgpjj^^  } 
Structure_List^p^^^ 

''END''  ''IF'' 


Process Termination 
RecPredicare 

RecD is junction 


;  :=  ''REMOVE''  GlobalF rocessName  List  _ 

—  comma 

:;=  RecDis junction  , 

RecPredicate  ' 'OR' '  RecDis junction 

:  :=  RecCon junction  , 

RecDis junction  '  'AND' '  RecCon junction 

;  :=  RecRelation  , 

''NOT"  '('  RecPredicate  ')' 


RecCon junction 
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---  Equal 
--  Not  equal 
—  Greater 
--  Greater  than  or  equal 
--  Less 

--  Less  than  or  equal 

RecTerm  : :=  IntegerValue  , 

RealValue  , 

StringValue  , 

TimeValue 

Examples: 

if  CurrQnt_Tini«  >=  6:00:00  local  and  Currant_Tiin«  <  18:00:00  local 
then 

process 

p  vision:  task  vision  attributes  procassor  =  w«.rp2 ; 
queue 

<^vision_road:  p_daal.out3  >  >  p_vision.ini; 

c^obstaclas :  p_viaion . outl  >  >  p_marg« . in3 ; 

end  if; 


RecRelation 


RecTerm  '  '  =  ' '  RecTerm  , 
RecTerm  '  '/  =  ' '  RecTerm  , 
RecTerm  '  '  RecTerm  , 

RecTerm  RecTerm  , 

RecTerm  '  '  RecTerm  , 

RecTerm  '  '<=' '  RecTerm  , 


Meaning: 

A  reconfiguration  statement  is  a  directive  to  the  scheduler.  It  is  used  to  specify  changes  in  the  current 
structure,  i.e.,  process-queue  graph,  of  the  application  and  the  conditions  under  which  these  changes 
take  effect.  Typically,  a  number  of  existing  processes  and  queues  are  substituted  by  new  processes  and 
queues  which  are  then  connected  to  the  remainder  of  the  original  graph.  The  reconfiguration  predicate  is 
a  boolean  expression  involving  time  values,  queue  sizes,  and  other  information  available  to  the  scheduler 
at  run  time. 


Notice  that  nothing  is  being  said  about  the  internal  representation  of  time  values.  They  are  definitely  not 
like  integer  or  real  values  --  time  values  cannot  be  mixed  with  regular  numeric  values  in  an  expression.  In 
addition,  currently  the  language  does  not  provide  any  arithmetic  operators  for  time  values.  However,  a 
few  predefined  system  functions  provide  for  the  computation  of  past  or  future  time  values,  as  described  in 
Section  10.1 . 
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10.  Predefined  Language  Facilities 


10.1.  Functions 
Syntax: 

FunctionName  {  FunctionParameters  } 

' 'CURRENT_TIME' '  , 

' 'MINUS_TIME' '  , 

' 'PLUS_TIME' '  , 

' 'CURRENT_SIZE' ' 

M'  Parameter  List  --  Function  dependent 

IntegerValue  , 

RealValue  , 

StringValue  , 

TimeValue 

Examples: 

Plus_Tiin«  {Curr«nt_Tiin« ,  2.5  hours) 

Currant_Siz«  (Kast«r__Proc«88  .Data_Port.) 

Meaning: 

The  following  functions  are  predefined  in  the  language;  "currenMime”,  "minusjime",  “plusjime”,  and 
‘‘current_size” 

The  function  call  “Current_Time”  returns  the  current  time  as  an  absolute  date  in  the  local  time  zone. 

The  function  call  ‘■Minus„Time(TimeValue^,TimeValue2)”  returns  the  time  value  obtained  by  subtracting 
TimeValue2  from  TimeValue^.  The  following  cases  are  allowed: 

1.  If  both  parameters  are  absolute  times,  the  result  is  a  relative  time,  i.e.,  a  duration. 
TimeValue^  must  be  later  than  TimeValue2. 

2.  If  TimeValue^  is  an  absolute  time  and  TimeValue2  is  a  relative  time,  the  result  is  an 
absolute  time  in  the  same  time  zone  as  TimeValue.,. 

3.  If  both  parameters  are  relative  times,  the  result  is  a  relative  time.  TimeValue^  must  be 
larger  than  TimeValue2. 

The  function  call  “Plus_Time(TimeValue.|,TimeValue2)”  returns  the  time  value  obtained  by  adding 
TimeValue2  to  TimeValue,.  The  following  cases  are  allowed: 

1.  If  one  parameter  is  an  absolute  time  and  the  other  parameter  is  a  relative  time,  the  result  is 
an  absolute  time  in  the  same  time  zone. 

2.  If  both  parameters  are  relative  times,  the  result  is  a  relative  time,  i.e.,  a  duration. 

The  function  call  “Current_Size(GlobalPor1Name)”  returns  the  current  number  of  elements  stored  in  the 
queue  associated  with  a  given  port. 

Calls  to  these  functions  can  appear  anywhere  a  value  of  the  same  kind  as  the  return  value  can  appear. 
That  is,  a  call  to  a  function  returning  an  integer,  a  real,  a  string,  or  a  time  value  can  appear  instead  of  an 
integer,  a  real,  a  string,  or  a  time  value,  respectively. 


--  2.5  hours  from  th«  currant  tima 
--  tha  fliza  of  a  quaua  faading  a  port 


FunctionCall 

FunctionName 

FunctionParameters 

Parameter 
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10.2.  Attributes 

The  following  attributes  are  predefined  in  the  language;  ‘‘mode",  "implementation”,  and  "processor". 

10.2.1.  Mode  Attribute 
Syntax; 

ModeAttr  ::=  ''MODE''  ' '  =  ' '  ModeAttrValue 

ModeAttrValue  ; ;=  Identifier 

Meaning: 

The  values  of  the  "mode"  attribute  are  identifiers  denoting  the  operation  performed  by  one  of  the 
predefined  tasks:  “broadcast",  "merge",  and  "deal",  as  described  in  Section  10.3. 

The  formal  specification  of  the  operation  is  given  by  the  behavioral  part  of  the  task  description.  The 
identifiers  used  as  values  for  the  "mode"  attribute  are  just  a  convenient  shorthand  to  select  what  are 
expected  to  be  frequently  used  tasks.  Users  are  more  likely  to  select  predefined  tasks  by  specifying  a 
mode  value  (i.e.,  an  identifier)  than  by  specifying  a  timing  expression  or  a  function  predicate. 

The  following  identifiers  are  representative  of  typical  values  for  the  “mode"  attribute;  "random",  "fifo", 
"round_robin",  “by_type",  "balanced",  ‘‘grouped_by_2".  The  actual  values  are  implementation 
dependent. 

10.2.2.  Implementation  Attribute 
Syntax: 

ImplementationAttr  : :=  ' 'IMPLEMENTATION' '  ' '=' '  Implement at ionAttrValue 

ImplementationAttrValue  : ;=  StringValue 

Examples: 

implomantation  =  " /uar/cbw/hetO/damo . o" ; 

Meaning: 

The  value  of  the  implementation  attribute  is  the  name  of  the  file  containing  the  actual  object  code.  The 
format  of  a  file  name  may  vary  with  the  host  operating  system. 


10.2.3.  Processor  Attribute 


Syntax: 

ProcessorAttr  : :=  ''PROCESSOR''  ' '  =  ' '  ProcessorAttrValue 


P rocessor At t rvalue 


Identifier  , 

Identifier  '('  Identifier  List  ^  ')' 

'  —  coxnnui  ' 


Examples: 

procassor  =  in68000  (m68020,  m68032)  ; 
procassor  =  m68020(pl,  p2,  p3) ; 
procaasor  =  in68032  (p4,  p5)  ; 
procassor  =  ibml401; 
procasaor  =  warp(warpl,  warp2) ; 
procassor  =  buf far_procassor; 
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Meaning: 

The  configuration  of  the  heterogeneous  machine  specifies  the  different  values  for  the  “processor” 
attribute,  including  names  of  classes  of  processors  as  well  as  names  of  individual  processors,  as 
illustrated  above.  See  Section  10.4  for  details  about  specifying  the  configuration  of  the  heterogeneous 
machine. 

The  value  of  the  “processor”  attribute  can  vary  in  specificity  by  using  a  processor  class  name  or  an 
individual  processor  name.  For  example,  WARP  means  any  Warp  processor;  WARP1  means  that  Warp 
processor. 

If  the  user  specifies  the  name  of  a  class  of  processors  as  the  valu'"  of  the  “processor”  attribute,  any  one 
of  the  members  of  the  class  can  be  used  to  execute  the  task.  If  the  user  specifies  a  class  name  and  a  set 
of  members  (in  parentheses),  any  one  of  the  members  of  this  set  can  be  used  to  execute  the  task.  The 
members  of  the  set  must  be  a  subset  of  the  class  as  defined  by  the  configuration. 

10.3.  Tasks 

The  following  tasks  are  predefined  in  the  language;  “broadcast”,  “merge”,  and  “deal”. 

10.3.1.  Broadcast 

“broadcast”  is  a  task  with  one  input  port  and  as  many  output  ports  as  needed.  Input  data  are  replicated 

and  sent  to  all  the  output  ports.  Port  names  are  in1  for  the  input  port  and  out1,  out2 .  outN  for  the 

output  ports. 

10.3.2.  Merge 

“merge”  is  a  task  with  one  output  port  and  as  many  input  ports  as  needed.  The  type  of  the  output  port  is 
the  union  of  all  the  input  types.  Input  data  items  are  merged  and  sent  to  the  output  port.  Port  names  are 
in1,  in2 . /nA/for  N  input  ports  and  out1  for  the  output  port. 

A  merge  discipline  must  be  provided  as  a  value  to  the  "mode”  attribute,  as  described  in  Section  10.2.1. 
Possible  values  include  “random”  (unordered),  “fifo”  (ordered  by  time  of  arrival  to  the  merge  process), 
and  “round_robin”  (one  from  each  input  port  and  repeating.)  Because  of  transmission  delays,  the  order 
of  arrival  of  the  data  might  differ  from  the  order  in  which  the  data  were  sent  out.  A  FIFO  merge  process 
uses  time  of  arrival,  not  time  of  creation,  to  order  the  data. 

10.3.3.  Deal 

“deal”  is  a  task  with  one  input  port  and  as  many  output  ports  as  needed.  The  type  of  the  input  port  is  the 
union  of  all  the  output  types.  Input  data  items  are  sent  to  one  output  port.  Port  names  are  in1  for  the 
input  port  and  out1,  out2,...,  ouf/V  for  the  output  ports. 

A  deal  discipline  must  be  provided  as  a  value  to  the  “mode”  attribute,  as  described  in  Section  10.2.1. 
Possible  values  include  "random”  (unordered),  ‘Tound_robin”  (one  to  each  output  port  and  repeating), 
“by_type”,  “grouped_by_2”,  and  “balanced”.  If  dealing  by  type,  the  output  port  must  be  uniquely 
identifiable  (i.e.,  there  is  exactly  one  output  port  of  the  right  type  for  each  possible  type  accepted  by  the 
input  port.)  This  is  the  only  kind  of  “deal”  process  in  which  multiple  output  types  make  sense.  Other 
kinds  of  "deal”  processes  require  compatible  output  types. 
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10.3.4.  Illustrative  Task  Descriptions 

Figure  9  illustrates  typical  task  descriptions  for  the  predefined  tasks.  The  task  description  in  Figure  9. a 
depicts  a  2-outpui  broadcast  task  that  handles  items  of  some  type  “packet"  in  parallel.  The  task 
description  in  Figure  9.b  depicts  a  2-input  merge  task  that  handles  items  of  type  packet  in  round  robin 
fashion.  Finally,  the  task  description  in  Figure  9.c  depicts  a  2-output  deal  task  that  handles  items  of  type 
packet  in  round  robin  fashion. 


task  broadcast 
ports 

ini:  in  pack.«t; 
outl,  out2 :  out  packat; 
behavior 

ensures  "inaart (outl,  first (ini))  &  insart(out2,  first (ini)) 
timing  loop  (ini  (outl  ||  out2)) 
attributes 

moda  =  parallal; 
end  broadcast; 


a.  Parallel  Broadcast 


task  marga 
ports 

ini,  in2 ;  in  packat; 
outl:  out  packet; 
behavior 

ensures  "insart  (insart  (inaart  (outl,  first  (ml)  )  ,  first  (in2)  )  ,  first  (in3)  )  "  ; 
timing  loop  ((ini  in2  in3)  (rapaat  3  =>  outl)  )  ; 
attributes 

moda  =  aaquantial_round_robin; 
end  marga; 


b.  Round-Robin  Merge 


task  deal 
ports 

ini:  in  packat; 
outl,  out2 :  out  packat; 
behavior 

ensures  "insart (outl,  first (ini))  &  inaart (out2,  8acond(inl) ) " ; 
timing  loop  (ini  outl  ini  out2); 
attributes 

moda  =  sequent ial_round  robin; 
end  deal ; 


c.  Round-Robin  Deal 
Figure  9:  Predefined  Task  Descriptions 


These  descriptions  do  not  really  exist  in  the  library.  The  compiler  generates  them  on  demand  to  satisfy 
process  declarations  of  the  form: 

pb:  task  broadcast  attributes  mode  =  identifier;  end  broadcast; 
pm;  task  marga  attributes  moda  =  identifier  end  marga; 
pd:  task  deal  attributes  mode  =  identifier  end  deal; 


where  identifier  is  “parallel",  “sequential_round_robin”,  etc.,  as  defined  by  the  implementation. 
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10.4.  Configuration  File 

Information  about  the  configuration  of  the  heterogeneous  machine,  the  location  of  system  files  and 
libraries,  and  other  random  information  required  by  the  compiler,  library,  and  scheduler  appears  in  a 
configuration  file. 


processor  =  warp(warp  1,  warp2); 
processor  «  8un(sun_l,  sun_2,  sun_3) ; 
implementation  =  " /usr/cbw/het lib/ " ; 

def ault_input_operation  =  ("get",  0.01  seconds,  0.02  seconds); 

def ault_output_operation  =  ("put",  0.05  seconds,  0.10  seconds); 

def ault_queue_length  =  100; 

data__operation  =  ("fix",  "fix.o"); 

data_operation  =  ("float",  "float.©"); 

data_operation  =  ( " round_f loat " ,  "round.©"); 

data_operation  =  ( "truncate_f loat " ,  "trunc.o"); 


Figure  10:  Configuration  File 


The  configuration  file  In  Figure  10  illustrates  the  definition  of  the  hardware  configuration  (values  for  the 
"processor”  attribute),  the  location  of  the  system  task  implementations,  and  various  pieces  of  information 
about  queues  and  queue  operations. 

In  the  “processor"  attribute,  the  meaning  of  a  class  name  is  understood  by  the  scheduler  as  standing  for 
any  of  the  specific  values  in  the  class  (i.e.,  a  run-time  choice  of  processors).  Notice  that  this  choice  can 
be  restricted  by  the  user  in  a  task  description  by  specifying  a  subset  of  the  class,  and  restricted  even 
further  in  a  task  selection  by  specifying  an  even  smaller  subset  of  allowable  processors. 

The  example  configuration  file  also  specifies  the  location  of  system  files,  in  particular,  the 
implementations  of  system  tasks.  Additional  information  in  the  file  would  describe  default  queue 
operations,  data  transformations,  etc. 

Keep  in  mind  that  the  configuration  file  is  not  written  in  the  task  description  language.  The  example 
shown  is  just  an  illustration  of  the  kinds  of  information  that  are  likely  to  be  contained  in  the  tile  —  form  and 
content  of  the  file  are  implementation  dependent. 
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11.  Appendix  --  An  Extended  Example 

This  appendix  illustrates  a  task-level  description  of  a  fictional  application.  A  process-queue  graph  of  the 
application  appears  in  Figure  1 1. 


11.1.  Data  Transformation  Tasks 

task  com«r  t’lrning 
ports 

ini:  in  lajidinArk_row_ma jor; 
outl;  out  landiaark  column  major; 
attributtts 

implamantation  =  "/usr/mrb/scr«®tch . o" ; 
processor  =  buffar  procassor; 

other  attnbutes  uniquely  identifying  an  implementation  .  .  . 

and  cornar_tuming; 


11.2.  Type  Declarations 


typo  map  databaso  is 

typo  dostination  is 

typo  local  jjath  is  . 

typo  rocognizod  road  is 

typo  road_soloction  is  . 

tjpo  vohiclo_position  is  . 

typo  v«hiclo_mot ion  is  . 

typo  whool" motion  is 

t^po  landmark  is 

typo  landmark_list  is 

typo  landnark_row_ma jor  is  . 

typo  landmark  colunin_ma jor  is 
typo  vision_road  is 

typo  aonar__road  is  . 

typo  laaor_road  is  . 

typo  road  is 

typo  obstaclos  is 


11.3.  Task  Descriptions 

task  navigator 
ports 

ini:  in  map_databaso/ 
in2 ;  in  dostination; 
outl;  out  road  soloction; 
out2 :  out  landmark_liat ; 
attributos 

author  =  "jmw"; 
vorsion  =  "1.0"; 
procossor  =  "m68020"; 
ond  navigator; 

task  road_jprodictor 
ports 

ini:  in  map_databaso; 
in2 ;  in  road  soloction; 
in3  in  vohiclo__position; 
outl;  out  road; 
ond  road_prodictor; 

task  landniark_prodictor 
ports 

ini:  in  landmark_li8t ; 
in2 :  in  vohiclo_j50sition; 
outl;  out  landmark  row  major; 
ond  landmark__prodictor; 


nil 
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tusk  road_finder 
ports 

ini:  in  road; 

outl;  out  racognized_road; 
and  road_f indar; 

task  landmark  racognirar 
ports 

ini:  in  landmark_column_mai jor; 
outl:  out  landmark  colxinui  major; 
and  landmark_recc'gnizar; 

task  vision 
ports 

ini:  in  vision_road; 
outl;  out  obstaclas; 
attributas 

procasjor  =  warp; 
and  vision; 

task  sonar 
ports 

ini :  in  sonar_road; 
outl:  out  obstaclas; 
attributas 

procassor  =  warp; 
and  sonar; 

task  lasar 
ports 

ini;  in  lasar  road; 
outl:  out  obstaclas; 
attributas 

procassor  =  warp; 
and  lasar; 

task  position  computation 
ports 

ini:  in  landmiirk_^columii_ma jor ; 
in2 :  in  vehicla_mot ion ; 
out^,  out2 :  out  vohicla_po8it.  on; 
and  poaition_coinputation; 

cask  local_path_plannar 
ports 

ini:  in  whael  motion; 
in2 :  in  obstacles; 
outl:  out  local_j)ath; 
out2 :  out  vahicla_motion; 
and  local_j)ath__plani\ar; 

task  vehicle  control 
ports 

ini;  in  local_psth; 
outl :  out  wheal_mot ion; 
end  vehicle  control; 
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task  obstacla_f indor 
ports 

ini:  in  racogni z«d_road; 
outl •  -  t  obstacltts; 

boha'vior 

l-'op  (inlflO,  15]  outl[3,  4]); 
structura 
procass 

p  daal :  task  daal  attributas  moda  =  by  typa  and  daal; 
p_marga:  task  marga  attributas  moda  =  fifo  and  marga; 
p_sonar;  task  sor.ar; 

p_lasar:  task  lasar  attributas  pr-ocassor  =  warpl  and  lasar; 
bind 

p  daal . ini  =  obstacla_findar.ini; 
p  marga. outl  "  obstacla  findar.outl; 
quaua 

ql:  p_sonar.outl  >  >  p_marga.ini; 
q2 :  p  lasar. outl  >  >  p_marga . in2 ; 
q3 :  p  daal. outl  >  >  p  sonar.ini; 
q4 :  p_deal.outl  >  >  p_la3ar.ini; 

--for  dynamic  raconf iguration 

if  Currant_Tima  >=  6:00:00  local  and  Currant_Tima  <  18:00:00  local 
than 

procass 

p  vision:  task  vision  attributas  processor  =  warp2;  vision; 

quaua 

q5 :  p_daal.out3  >  >  p_vis ion . ini / 
q6  :  p_vi8  ion  .  outl  >  >  p_me  %i.in3; 
and  if; 

and  obstacla  findar; 


11  V  Application  Description 

tasK  ALV 

attrib.itas 

version  =  "Fall  1986"; 
processor  =  HETO; 
speed  =  fast; 
structure 
procass 

navigator:  task  navigator  attributes  author 


■jmw"  end  navigator; 


rood_p.-adictor : 
landmark_j.  radict  or : 
road  findar: 


task  roadjpredictor; 
task  landniark_pradictor ; 
task  road  findar; 


landmark_racognizar :  task  landmark_racognizar ; 
obstaclo_f indor :  task  obs tacla_f indar ; 

pos ition_ccmputat ion : task  position_computation; 
local__path_plannor :  task  local_path_plannar ; 


vehicle  control: 
ct__proca8s  : 


task  vehicle  control; 
task  corner  turning; 


quaua 

ql: 

navigator . outl 

> 

> 

road_pradictor . in2 ; 

q2: 

navigator . out2 

> 

> 

landmrrk_predictor .  ini ; 

q3: 

road__pradictor .  outl 

> 

> 

road  findar.ini; 

q4: 

road  findar.outl 

> 

> 

ob8tacla__f  indar .  ini ; 

q5: 

obstacla  findar.outl 

> 

> 

local_path_plannar . in2 ; 

q6: 

local_path_plannar . outl 

> 

> 

vehicle  control.ini; 

q7: 

local_path_plannar . out2 

> 

> 

po8ition_conputation . in2 ; 

q8; 

vahicla_control . outl 

> 

> 

local_path_plannar . ini ; 

q9: 

landroark_pradictor . outl 

> 

ct_proca88  >  landmark  racognizar.ini; 

--  ^.aquiras  data  transformation  between  row  major  and  column  major  landmarks 
qlO  :  landmark  racogrnizar .  outl  >  >  position  coinputation.ini; 
qll: position  computation . outl>  >  road_pradictor . in2 ; 
ql2  ;  posit  ion_computat  ion  .  out2>  >  landmark__p  radict  or .  in2  ; 
and  ALV; 
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